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Executive  Summary 


Problem  Definition  The  Army’s  Soldier  as  a  System  requirement  identifies  capability  gaps  with  respect  to  dis¬ 
mounted  battle  command  and  situation  awareness.  As  compared  to  their  mounted  peers,  dismounted  soldiers 
lack  effective  radio  communications,  situation  awareness  displays,  and  request  or  reporting  systems  that  integrate 
with  other  elements  of  the  combined  arms  team.  In  particular,  networked  voice  and  data  communications,  a  user- 
defined  situation  awareness  picture,  networked  lethality,  and  mission  planning  and  rehearsal  are  not  available  to 
dismounted  soldiers  via  their  organic  command  and  control  systems. 

The  Army’s  Nett  Warrior  system  will  address  some  of  the  needs  for  dismounted  command  and  control.  This  pro¬ 
gram  is  slated  to  reach  initial  operating  capabilities  in  2012  with  improvements  and  full  operating  capabilities  in 
2016.  Even  after  successful  development  and  fielding  of  the  Nett  Warrior  system,  complemented  by  the  SINC- 
GARS  (ASIP)  radio,  there  will  still  be  some  challenges  and  capability  gaps  with  respect  to  dismounted  command 
and  control.  First,  these  systems  are  scheduled  to  be  fielded  to  infantry  units.  However,  many  other  units  perform 
dismounted  operations.  In  addition,  concerns  about  overall  system  weight  and  cost  remain.  Finally,  the  challenge 
of  integrating  allied  and  host  nation  forces  will  be  difficult  with  these  systems. 


Technical  Approach  This  project  looks  to  emerging  commercial  technologies  for  mobile  cellular  networks  as  a 
cost  effective  means  to  fill  these  gaps.  These  technologies  are  in  wide  use  across  the  international  commercial 
sector  and  allow  robust  and  high  bandwidth  communications  in  a  very  small  package.  They  are  employed  in  all 
types  of  terrain,  and  international  standards  have  emerged  that  allow  communications  between  disparate  systems. 

This  project  performed  stakeholder  analysis  across  the  dismounted  community  to  better  define  the  overall  value 
this  system  brings  to  the  battlefield.  Based  on  this  analysis,  we  developed  an  overarching  value  model  to  support 
value  focused  design  of  alternatives.  These  alternatives  were  evaluated  in  a  modeling  and  simulation  environment 
that  assessed  communications  effects  and  tactical  effects  on  the  battlefield.  A  significant  portion  of  the  effort  for 
this  project  was  the  development  of  these  modeling  and  simulation  capabilities.  In  addition,  network  and  device 
security  concerns  were  integrated  into  the  analysis. 

A  parallel  effort  leveraged  an  international  command  and  control  standard,  the  Coalition  Battle  Management  Fan- 
guage  (CBMF)  to  develop  interoperability  protocols,  orders  passing,  and  message  passing  via  mobile  devices  be¬ 
tween  coalition  partners. 


Results  With  respect  to  analysis  results,  the  study  team  concluded  that  a  brigade/battalion  owned  CDMA  net¬ 
work  delivered  the  most  value  at  the  lowest  cost  as  compared  to  Nett  Warrior  systems.  This  is  a  standalone  unclas¬ 
sified  network  owned  by  the  brigade.  The  brigade  decides  who  to  allow  to  enter  the  network  and  what  information 
to  provide  on  that  network.  The  network  consists  of  static  cell  towers  on  bases,  mobile  cell  towers  in  vehicles,  and, 
if  necessary,  dismounted  cell  towers  covering  small  patrols.  Cell  to  cell  communications  are  handled  by  a  portable 
high  bandwidth  device  such  as  the  F3  Communications  Rover  5.  This  system  also  allows  the  integration  of  UAV 
video  into  the  network.  Individual  soldiers  or  vehicle  commander  carry  commercially  available  handheld  phones 
-  optionally  with  external  amplifiers  and  antennas  to  support  longer  ranges. 

Security  is  a  significant  concern  for  mobile  commercial  technologies.  However,  after  a  visit  with  the  National 
Security  Agency’s  secure  wireless  division,  we  found  that  a  combination  of  commercially  available  encryption 
technologies  would  be  adequate  for  a  disconnected  brigade  level  network.  For  transmission,  these  technologies 
included  a  secure  VPN  coupled  with  an  additional  layer  of  data  encryption  to  pass  both  voice  and  data  along 
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the  data  channel.  The  CDMA  spread  spectrum  technology  added  an  additional  layer  of  inherent  security  and 
jamming  resistance.  Device  security  could  be  accomplished  by  encrypting  all  data  stored  on  the  device  along 
with  a  combination  code/token  authentication  system.  This  gives  network  managers  an  ability  to  almost  instantly 
grant  or  deny  access  to  users  as  the  tactical  situation  dictates. 

Modeling  and  analysis  showed  that,  although  this  network  had  shorter  radio  ranges  than  current  systems,  radio 
relay  technologies  significantly  improved  performance  to  acceptable  levels.  Its  overall  lower  weight,  intuitive  in¬ 
terface,  and  expanded  features  delivered  significantly  higher  value.  In  addition,  the  availability  of  commercial 
technologies  drives  the  cost  of  this  system  well  below  the  Nett  Warrior  system,  and  it  allows  more  users  on  the 
network  because  of  the  low  relative  cost  of  individual  devices. 

In  addition  to  these  analysis  results,  the  study  team  worked  with  simulation  and  communications  experts  to  de¬ 
velop  a  robust  communications  analysis  suite  that  enables  both  stand-alone  communications  analysis  and  com¬ 
munications  effects  integrated  with  combat  simulation.  The  core  of  this  infrastructure  is  the  COMPOSER  (The 
Communications  Planner  for  Operational  Effects  with  Realism)  model  developed  by  US  Army  Communications 
Electronics  Research  Development  and  Engineering  Center.  In  stand-alone  mode,  it  quickly  models  complex  com¬ 
munications  architectures  at  the  unit  level.  When  integrated  with  the  Army’s  Modeling  Architecture  for  Technol¬ 
ogy,  Research,  and  Experimentation,  it  allows  simulation  players  to  see  situation  awareness  pictures  as  affected  by 
communications  propagation  and  interference. 

When  the  CBML  message  passing  capability  was  integrated  with  this  architecture,  the  project  yielded  a  prototype 
mobile  phone  system  that  could  exchange  orders,  messages,  and  situation  awareness  with  the  Army’s  One  Semi- 
Automated  Forces  (OneSAF)  simulation  system. 
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IV 


2  STAKEHOLDER  ANALYSIS 


1  Background 

Shoot,  move,  communicate.  These  are  the  critical  ac¬ 
tions  a  dismounted  combat  unit  must  be  able  to  per¬ 
form  in  order  to  be  effective  on  the  battlefield.  Of 
these  three  actions,  communication  is  the  most  impor¬ 
tant  because  it  precedes  and  directs  how  a  dismounted 
unit  shoots  and  moves.  Communication  is  also  key 
in  coordinating  combat  and  logistics  support.  Unfor¬ 
tunately,  the  current  communications  systems  in  use 
are  much  more  effective  for  mounted  units  than  dis¬ 
mounted  units.  Our  mission  is  to  provide  analysis  that 
will  inform  and  direct  the  decisions  of  Army  leadership 
as  it  provides  new  communication  systems  to  all  dis¬ 
mounted  units  which  modernize  and  improve  military 
communications.  Some  ideas  that  are  being  considered 
include  tablet  PC  or  smart  phones.  Some  issues  with 
these  commercial  devices  are  that  the  army  would  have 
to  coordinate  with  the  companies  themselves  and  se¬ 
cure  the  devices. 

Currently  in  theater  they  use  a  SINCGARS  (ASIP)  radio. 
It  has  the  ability  to  talk  over  different  radio  nets,  but  it  is 
limited  to  voice.  The  stakeholders  we  talked  to  seemed 
to  be  content  with  the  way  the  system  worked  and  said 
that  in  a  firelight  they  would  “forget  about  the  fancy 
technology  and  resort  to  the  way  they  had  always  done 
things”.  The  way  they  had  always  done  things  would  re¬ 
fer  to  using  a  radio  to  communicate  and  carry  out  the 
mission.  The  SINCGARS  radio  is  effective,  but  the  ques¬ 
tion  is,  “How  much  more  effective  an  alternative  system 
would  be  in  comparison  to  what  is  currently  being  used 
in  theater?” 


2  Stakeholder  Analysis 

Prior  to  developing  a  value  model  and  considering  al¬ 
ternatives,  the  design  team  interviewed  a  series  of  ex¬ 
perienced  stakeholders  from  the  West  Point  commu¬ 
nity  to  try  to  understand  their  needs  with  respect  to  dis¬ 
mounted  command  and  control. 

Army  SFC:  He  has  spent  over  15  years  enlisted  in  the  in¬ 
fantry.  He  was  adamant  about  the  army  in  general  not 
knowing  how  to  use  the  technology  they  already  had 


and  how  adding  new  technology  would  not  be  helpful. 
He  said  that  only  the  platoon  sergeant/platoon  leader 
and  up  would  need  the  new  technology  we  are  recom¬ 
mending.  Anything  below  this  would  take  far  too  long 
to  train,  and  it  would  not  be  helpful  in  any  manner. 
He  liked  all  of  the  operational  activities  that  we  have 
and  would  be  interested  to  see  a  piece  of  technology 
that  could  use  them  relatively  easily.  In  addition,  he 
was  doubtful  on  the  idea  of  us  translating  between  lan¬ 
guages  with  our  technology,  particularly  when  working 
with  the  Afghanistan  Police. 

Army  Captain-  deployed  to  Iraq  2006-2007  with  the 
101st  Airborne  Division  (Air  Assault).  He  picked  up  a 
platoon  mid  tour  and  was  immediately  thrown  into  ac¬ 
tion.  He  was  only  deployed  for  five  months,  but  was 
wounded  three  times.  These  consisted  of  two  IEDs  and 
one  ambush.  He  wished  he  had  some  sort  of  technology 
that  tracked  his  unit’s  actions  and  enemy  actions  in  the 
area  because  he  believed  the  enemy  had  operated  in  the 
area  previously. 

Army  1LT:  We  asked  him  if  he  or  any  of  his  Soldiers  had 
used  the  Nett  Warrior  system  before.  He  had  not  per¬ 
sonally  used  Nett  Warrior,  but  his  platoon  sergeant  had 
in  2008  at  Ft.  Benning  during  a  training  exercise.  The 
feedback  he  gave  was  that  it  was  too  heavy  for  the  ben¬ 
efits  it  gave  his  unit.  He  continued  saying  that  he  would 
not  bring  it  outside  the  wire  with  him. 

Army  SFC:  He  has  served  in  the  Ranger  Regiment  and 
participated  in  several  deployments.  His  main  focus 
was  ensuring  that  whatever  technology  was  being  con¬ 
sidered  as  a  candidate  solution  should  be  easy  to  train 
soldiers  to  use.  He  said  one  of  the  largest  issues  he  had 
noticed  is  that  soldiers  often  do  not  know  how  to  prop¬ 
erly  operate  the  communications  equipment  they  cur¬ 
rently  have.  If  soldiers  do  not  know  how  to  properly  use 
the  technology,  it  is  essentially  useless.  He  used  com¬ 
munications  technology  in  the  Ranger  Regiment  similar 
to  some  of  the  systems  being  examined  by  our  capstone 
group.  This  equipment  provided  video  feed,  GPS,  and 
text  capabilities.  He  warned  that  these  systems  are  of¬ 
ten  very  expensive,  and  may  not  always  provide  enough 
value  for  that  cost.  During  operations,  he  said  most 
of  the  rangers  equipped  with  these  devices  did  not  use 
them.  He  advised  that  we  find  something  durable,  that 
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is  easy  to  use /train  to  use,  and  provides  an  array  of  ca¬ 
pabilities  such  as  GPS  and  text  communications  that 
would  benefit  a  soldier  only  at  times  when  not  engaged 
with  the  enemy.  He  also  advised  that  no  one  below  the 
level  of  squad  leader  should  receive  a  system. 

Army  SFC:  He  has  served  12  years  in  the  Army  through 
multiple  deployments.  He  said  the  systems  would  be 
useful  in  dismounted  command  and  control,  but  in  or¬ 
der  for  our  system  to  be  useful  to  the  soldier  it  would 
need  to  be  durable.  He  commented  that  if  it  broke  ev¬ 
ery  time  a  soldier  dropped  it,  the  soldier  would  not  carry 
it.  He  also  noted  that  the  batteries  used  in  this  system 
would  need  to  last  at  least  12  hours.  The  batteries  would 
need  to  be  small  and  light  in  order  to  lessen  the  amount 
of  weight  carried  by  a  soldier  on  a  mission.  Further¬ 
more,  this  system  would  need  to  have  various  layers  of 
security  to  protect  the  information  on  it  if  it  were  lost 
or  stolen.  Otherwise,  this  system  would  be  too  much  of 
a  security  risk  to  take  on  missions.  He  stated  that  this 
system  should  be  able  to  support  voice  and  text  com¬ 
munications,  it  should  be  light,  using  it  should  be  easy, 
and  it  should  facilitate  the  request  and  coordination  of 
combat  support  assets. 


3  Operational  Architecture 

The  capabilities,  operational  activities,  values,  and  met¬ 
rics  of  assessment  for  the  proposed  system  were  orga¬ 
nized  into  a  systems  architecture  for  dismounted  com¬ 
mand  and  control. 


3. 1  Capabilities  Viewpoint 

The  Capability  View  1  (CV-1)  is  part  of  defining  the  ca¬ 
pabilities  we  want  for  our  system.  This  view  is  the  high¬ 
est  level  view  and  shows  the  overall  vision  of  the  sys¬ 
tem.  Our  vision  for  this  system  is  to  provide  dismounted 
command/ control  to  different  unit  types.  In  this  view 
we  display  the  desired  effects  or  the  organizational  ob¬ 
jectives.  The  desired  effects  are  more  specific  than  the 
vision;  however  they  feed  into  the  vision  of  the  overall 
system.  After  talking  to  stakeholders,  we  found  that  we 


have  four  capabilities  that  define  our  system.  The  entire 
CV-1  can  be  seen  in  Figure  1. 

The  Capability  View  2  (CV-2)  is  part  of  the  system  archi¬ 
tecture  that  defines  each  capability.  The  capabilities  of 
this  system  are  communicate  with  higher  and  adjacent 
units,  understand  friendly  situation,  understand  enemy 
situation,  and  simplify  and  expedite  reporting/requests. 
In  Figure  2  you  can  find  the  descriptions  of  each  of  these 
capabilities.  The  most  important  fact  about  each  of 
these  capabilities  is  that  they  are  all  looked  at  the  pla¬ 
toon  level. 

3.2  Operational  Viewpoint 

The  OV- 1  is  a  visual  representation  of  the  capabilities  we 
have  found  to  be  essential  through  stakeholder  analy¬ 
sis.  Not  all  capabilities  or  mission  threads  are  shown 
in  the  OV-1,  however,  the  concept  of  the  capabilities 
are  captured.  The  benefit  of  the  OV-1  is  that  it  shows 
not  only  what  capabilities  a  candidate  solution  technol¬ 
ogy  may  possess  but  also  shows  the  capabilities  neces¬ 
sary  to  a  dismounted  Army  mission.  A  prominent  take¬ 
away  from  the  OV-1,  shown  in  Figure  3,  is  the  level  of 
connectivity  that  the  dismounted  platoon  or  soldier  will 
experience  when  using  the  candidate  solution  technol¬ 
ogy.  They  will  be  connected  to  UAV,  aircraft,  other  dis¬ 
mounted  soldiers,  vehicles,  mortars /artillery,  GPS,  and 
higher  headquarters. 

The  OV-5a  as  shown  in  Figure  4,  covers  our  system  ca¬ 
pabilities,  operational  activities,  and  system  functions. 
It  is  using  the  same  system  capabilities  as  shown  in  the 
CV-2.  The  important  elements  of  the  OV-5a  are  the  Op¬ 
erational  Activities:  Communicate  with  Allied  Forces, 
Acquire  Video  Feed,  Send  SITREP,  Request  MEDEVAC, 
Request  EOD,  Track  Enemy  Forces,  Track  Allied  Forces, 
Request  Fires,  Conduct  Movement  during  the  Mission, 
and  Prepare  for  Mission.  From  these  activities  we  de¬ 
cided  on  functions  we  would  want  our  system  to  per¬ 
form,  and  these  will  further  be  broken  down  in  our 
Value  Hierarchy. 

We  created  a  mission  thread  for  each  of  our  Operational 
Activities  mentioned  in  Architecture  OV-5a.  These  mis¬ 
sion  threads  are  shown  in  Annex  A,  depicted  as  a  series 
of  OV-5b  -  Operational  Activity  Models.  These  Mission 
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3  OPERATIONAL  ARCHITECTURE 


Desired  Effects 
(Organizational 
Objectives) 


Capabilities 


Figure  1:  CV-1  Capabilities  View  1  -  Vision. 


Communicate  with  higher  and  adjacent  units 

While  dismounted  and  away  from  support  vehicles  conducting  combat  operations,  the  platoon  leader  and  platoon  require  the  capability  to  communicate  with  higher  and  adjacent 
units  in  order  to  effectively  command  and  control  the  battlefield 


Understand  Friendly  Situation 

While  dismounted  and  away  from  support  vehicles  conducting  combat  operations,  the  platoon  leader  and  platoon  require  the  capability  to  track  fnerwJly  units  withm  thee  area  of 
operations  in  order  to  prevent  fratricide  and  improve  command  and  control 


Understand  Enemy  Situation 

While  dismounted  and  away  from  support  vehicles  conducting  combat  operations,  the  platoon  leader  and  platoon  require  the  capability  to  track  enemy  units  within  their  area  of 
opera  lions  in  order  10  locate,  track  and  destroy  the  enemy 


Simplify  and  expedite  reporting/requests 

While  dismounted  and  away  from  support  vehicles  conducting  combat  operations,  the  platoon  leader  and  platoon  require  the  capability  to  easily  and  effectively  send  reports  to 
higher  or  to  subordinate  units  in  order  to  minimize  time  spent  requesting/waiting  for  supplies,  information,  or  support 

Figure  2:  CV-2  Capabilities  View  2  -  Capability  Taxonomy. 
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Figure  3:  OV-1  -  High  Level  Operational  Concept  Graphic. 


Figure  4:  OV-5A  -  Operational  Activity  Decomposition  Tree 
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4  VALUE  MODELING 


Threads  go  through  each  of  our  operational  activities 
step  by  step  to  show  the  different  steps  that  our  system 
is  going  to  be  needed  for.  We  need  to  make  sure  that 
the  software  has  the  capability  to  perform  all  of  our  de¬ 
sired  effects.  Most  of  the  threads  make  use  of  an  radio¬ 
telephone  operator  (RTO),  which  is  currently  how  re¬ 
ports  are  done  on  the  SINCGARS  radio.  If  the  system 
we  choose  at  the  end  of  this  project  is  simple  and  quick 
enough,  the  platoon  leader  or  platoon  sergeant  may  be 
able  to  perform  the  role  of  the  RTO  and  save  time  in¬ 
stead  of  translating  to  the  RTO  to  send  messages.  An¬ 
other  point  of  the  mission  threads  is  to  show  things  that 
you  could  not  do  with  the  current  system,  such  as  re¬ 
questing  a  video  feed  from  a  UAV.  With  these  mission 
threads  we  can  show  what  our  system  is  going  to  need 
to  do.  They  give  us  a  framework  for  where  to  go  with  our 
software  and  hardware  requirements. 

4  Value  Modeling 

The  Value  Hierarchy  is  a  model  that  gives  us  insight  to 
the  operational  activities,  system  functions,  and  system 
objectives.  From  our  stakeholder  analysis  we  learned 
that  users  would  like  the  system  to  perform  the  fol¬ 
lowing  activities:  communication  with  allied  forces,  ac¬ 
quire  video  feed,  send  SITREP,  request  MEDEVAC,  re¬ 
quest  EOD  to  clear  IED,  track  allied  forces,  request  call 
for  fire,  conduct  movement  during  the  mission,  track 
enemy  forces,  and  prepare  for  mission.  These  oper¬ 
ational  activities  feed  into  our  nine  system  functions. 
System  functions  are  the  functions  that  the  dismounted 
command  and  control  system  performs  during  the  dis¬ 
mounted  squad’s  operational  activities.  The  nine  sys¬ 
tem  functions  are:  provide  text,  provide  voice  capabil¬ 
ities,  report  enemy/ friendly  location,  provide  visual  of 
enemy/ friendly,  deliver  report  templates  to  desired  unit 
(EOD,  SITREP,  call  for  fire,  MEDEVAC),  provide  comfort 
to  friendly  forces  for  duration  of  the  mission,  provide 
ease  of  training,  show  enemy  history  in  the  area,  and  en¬ 
crypt  the  device.  Each  of  our  system  functions  has  2-3 
objectives.  The  entire  value  hierarchy  is  shown  in  Figure 
5. 

Our  system  functions  fall  into  the  bottom  of  our  value 
hierarchy.  Each  system  function  has  at  least  one  value 


measure  attached  to  it.  The  value  measures  are  the 
criteria  for  how  we  are  going  to  score  our  alternatives. 
Most  of  our  value  measures  have  an  objective  measure 
to  them.  For  example  screen  resolution  has  a  value 
measure  of  mega-pixels.  When  looking  at  alternatives 
we  will  research  how  many  mega-pixels  it  is  and  score 
it  according  to  our  value  model.  However,  some  of  our 
value  measures  are  subjective  because  they  have  star 
ratings.  By  “star  ranking,”  we  refer  to  a  constructed  scale 
where  a  user  will  pick  up  our  device  and  rate  it  from 
1-5  stars  based  on  how  that  individual  feels  the  system 
should  be  scored.  Our  system  objectives  and  value  mea¬ 
sures  can  be  found  in  ANNEX  B. 

After  talking  to  stakeholders,  we  gathered  that  they  have 
many  important  value  measures.  However,  we  learned 
that  not  all  the  value  measures  are  as  important  to  them. 
For  example,  the  number  one  value  that  stakeholders 
said  is  that  if  it  is  too  heavy  they  will  not  use  it  at  all. 
One  of  the  value  measures  is  precision  of  location  for 
squad  size  element.  This  value  measure  means  how 
accurate  the  device  will  report  a  friendly/ enemy  unit. 
Stakeholders  stated  that  this  would  not  be  as  important 
as  weight,  battery  life,  or  simplicity.  The  value  measures 
that  stakeholders  said  are  most  important  are  in  the  up¬ 
per  left  corner  of  the  matrix  and  the  least  important  are 
the  value  measures  in  the  bottom  right  corner  of  the 
matrix.  The  entire  matrix  that  lists  all  of  our  value  mea¬ 
sures  can  be  seen  in  Figure  6. 

Value  models  give  a  numeric  value  score  to  a  specifi¬ 
cation  of  the  system.  With  these  we  can  compare  the 
value  of  our  base  case  to  the  value  of  the  different  op¬ 
tions  we  are  weighing  against  each  other.  This  will  allow 
us  to  get  a  total  number  that  we  will  be  able  to  translate 
into  a  score  of  1  to  100  which  will  be  talked  about  in  the 
Swing  Weight  Matrix  portion  of  this  report.  We  currently 
have  17  value  models  for  our  17  System  Objectives,  each 
with  a  shape  depending  on  the  value  associated  at  dif¬ 
ferent  levels.  We  determined  the  shapes  of  the  value 
models  after  talking  with  our  stakeholders  about  what 
they  thought  was  important  to  take  this  piece  of  equip¬ 
ment  on  dismounted  missions.  For  example,  weight  is 
an  extremely  important  consideration  to  the  war  fighter. 
The  war  fighter  will  already  be  carrying  50-70+  pounds 
at  temperatures  up  to  120°  F.  After  realizing  how  impor¬ 
tant  weight  would  be,  we  went  back  to  the  war  fighter 
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Figure  5:  Value  Hierarchy 
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Level  of  Importance  of  the  Value  Measure 

High 

Medium 

Low 

Weight 

100 

Fragmented  Video 

90 

Applications 

20 

High 

Battery  Life 

100 

Frame  Rate 

80 

Classification 

100 

Accuracy 

80 

c 

Training  Difficulty 

100 

9 

B 

Simplicity 

90 

Send/Receive  Time 

80 

r 

Medium 

Screen  Clarity 

85 

Voice  Clarity 

70 

> 

Completion  % 

85 

Transmissions 

60 

Propagation 

85 

Storage  Space 

55 

Comfort 

70 

Time  to  Learn 

50 

Precision  of  Location 

15 

Low 

Precision  of  Size  of  Unit 

15 

Figure  6:  Swing  weight  matrix.  This  matrix  gives  a  weight  to  each  value  measure  based  on  both  the  importance 
and  variability  of  that  measure  with  respect  to  the  range  of  feasible  alternatives. 


and  asked  how  much  additional  weight  they  would  be 
willing  to  carry  to  make  this  command  and  control  unit 
desirable.  We  set  our  ranges  of  0  lbs  as  ideal  and  10  lbs 
as  so  heavy  that  they  would  not  take  it  on  the  mission. 
All  of  our  value  models  are  shown  in  ANNEX  C. 


5  Alternatives 

The  alternatives  analyzed  in  this  project  are  Nett  War¬ 
rior,  tablet  PCs,  and  Smartphones.  Our  current  base¬ 
line  and  what  is  being  used  across  the  Army,  the  SINC- 
GARS  (ASIP)  radio.  The  Nett  Warrior  is  a  device  worn  by 
the  war  fighter  and  gives  the  user  more  capabilities  than 
the  ASIP  radio.  In  addition  to  voice,  it  provides  video, 
tracking  of  friendly  and  enemy  forces,  and  can  show  the 
unit’s  location  to  higher.  It  is  relatively  heavy  in  compar¬ 
ison  to  a  tablet  PC  or  smart  phone.  A  tablet  PC  or  Smart¬ 
phone  are  also  much  less  expensive  and  therefore  can 
be  more  easily  replaced.  One  problem  with  the  tablet 
PC  and  Smartphone  is  that  they  are  unsecure,  while  Nett 
Warrior  and  the  ASIP  radio  have  been  cleared  to  operate 
on  SECRET  networks  by  the  National  Security  Agency 
(NSA).  A  tablet  PC  and  Smartphone  are  extremely  simi¬ 
lar.  The  tablet  has  a  larger  screen  than  the  Smartphone, 
but  does  not  have  voice  capability.  One  big  disadvan¬ 
tage  of  these  two  options  is  that  they  are  less  durable 
than  the  Nett  Warrior  or  the  ASIP  radio. 


The  tablet  and  Smartphone  alternatives  each  include  an 
unclassified  secure  mobile  cell  network  at  the  brigade 
and  battalion  level  that  would  enable  their  use  in  an 
austere  environment.  The  Army’s  Connecting  Soldiers 
to  Digital  Apps  (CSDA)  program  is  testing  the  feasibility 
of  these  networks.  In  fact,  the  rapid  evolution  of  mo¬ 
bile  communications  in  the  commercial  sector  is  pro¬ 
viding  opportunities  to  adapt  commercial  technologies 
for  military  use.  While  the  focus  of  this  project  was 
not  to  design  a  mobile  network  for  military  usage,  the 
project  team  was  able  to  propose  a  simple  architecture 
and  a  set  of  broad  system  capabilities  as  illustrated  in 
Figure  7.  This  architecture  is  feasible  based  on  discus¬ 
sions  with  commercial  vendors,  CSDA  program  man¬ 
agers,  and  the  results  of  communications  modeling. 

The  architecture  envisions  a  brigade  or  battalion  level 
secure  unclassified  cellular  command  and  control  net¬ 
work  for  combined  operations  with  coalition  partners 
and,  as  determined  by  the  brigade  or  battalion  com¬ 
mander.  While  primary  intelligence  and  planning  will 
be  conducted  on  the  SECRET  network,  the  comman¬ 
der  will  allow  certain  elements  of  operational  and  intel¬ 
ligence  data  to  be  released  on  the  unclassified  network 
to  support  current  operations  and  command  and  con¬ 
trol.  The  timing  and  scope  of  release  will  be  determined 
by  the  operational  situation  and  associated  risk  of  com¬ 
promise. 

The  release  of  data  will  take  place  via  a  security  and 
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Figure  7:  Systems  View-1  Resource  Interaction  Specification  for  dismounted  command  and  control  alternative 
using  tablets  or  Smartphones. 
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translation  system  that  ensures  only  authorized  infor¬ 
mation  is  released  in  the  form  of  structured  messages 
or  video  feeds.  In  addition,  these  guards  will  ensure  that 
unclassified  systems  are  able  to  pass  structured  data  or 
video  feeds  to  the  higher  network  while  protecting  the 
higher  network  from  unauthorized  access. 

In  order  to  better  support  coalition  operations,  the  net¬ 
work's  operational  data  system  will  use  Coalition  Battle 
Management  Services  (CBMS).  Section  7  discusses  this 
further.  Tactical  messages  will  be  routed  to  the  server 
where  they  can  be  archived  and  compiled  for  subse¬ 
quent  publication  to  subscribed  mobile  devices.  The 
brigade  or  battalion  will  manage  message  distribution 
across  the  network. 

The  backbone  of  the  system  is  the  cellular  network. 
Several  subsystems  compose  this  network.  The  first  of 
these  is  an  array  of  cell  towers.  At  brigade  and  battal¬ 
ion  level,  units  will  own  a  combination  of  Forward  Op¬ 
erating  Base  (FOB)  towers  (brigade  and  battalion  level), 
vehicle  towers  (company  level),  and  dismount  towers 
(platoon  level).  These  towers  will  allow  the  establish¬ 
ment  of  cell  networks  with  25km,  10km,  and  5km  ranges 
respectively.  The  towers  will  run  an  IP  based  voice 
and  digital  network  using  code  division  multiple  ac¬ 
cess  (CDMA)  access  methods  to  enhance  security  and 
jamming  resistance.  The  second  element  of  the  cell 
network  is  a  collections  of  commercial  Smartphones, 
tablets,  and  personal  computers.  Any  of  these  devices 
will  be  able  to  access  the  cell  network  to  perform  com¬ 
mand  and  control  tasks,  given  they  have  the  appropri¬ 
ate  token  and  key  for  authentication. 

If  the  unit  needs  to  push  out  a  longer  range  operation, 
the  vehicle  mounted  or  dismounted  cell  tower  may  be 
deployed  well  away  from  the  FOB.  In  this  case,  a  long- 
range  high  bandwidth  communication  system  will  link 
the  forward  deployed  cell  network  to  the  main  network. 
In  order  to  reduce  necessary  bandwidth  on  the  long 
range  link,  the  unit  can  forward  deploy  a  CBMS  server 
and  video  server  so  that  these  media  can  be  transmit¬ 
ted  over  the  forward  deployed  cell  network.  Point  to 
point  communications  will  be  carried  over  this  network 
as  well.  This  will  limit  the  amount  of  video  and  data  that 
must  be  passed  over  long  range  communications  to  the 
main  network  at  the  FOB. 


The  design  team  met  with  the  National  Security 
Agency's  (NSA)  Secure  Wired/ Wireless  Division  in  or¬ 
der  to  understand  basic  security  requirements  for  a  dis¬ 
connected  cell  network.  The  security  system  would  re¬ 
quire  a  token  and  password  authentication  system  for 
access.  The  devices  entering  the  network  would  need 
to  be  able  to  read  the  token  and  present  a  password 
as  they  authenticated  onto  the  network.  A  disposable 
token  could  be  given  to  less  trusted  units,  and  this  to¬ 
ken  would  only  be  good  for  a  certain  level  of  access  for 
a  certain  duration  of  the  mission.  A  potential  alterna¬ 
tive  to  the  token /password  is  biometric  authentication. 
Data  and  voice  transmissions  would  be  subject  to  dual 
encryption.  The  wireless  signal  itself  will  be  encrypted 
by  the  phone  and  the  cell  tower  prior  to  transmission. 
In  addition,  the  respective  voice  or  digital  applications 
would  encrypt  their  data  prior  to  passing  it  to  the  device 
for  the  second  layer  of  encryption  and  transmission. 


Additional  meetings  with  the  CSDA  program  affirmed 
the  feasibility  and  potential  value  of  the  proposed  ar¬ 
chitecture.  Several  vendors  already  have  products  with 
similar  capabilities.  Lockheed  Martin's  MONAX  system 
was  tested  by  the  Army  Evaluation  Task  Force  in  De¬ 
cember  2010  at  the  platoon  level  with  some  promising 
results  (Army  Evaluation  Task  Force  AETF,  20 10)1.  The 
Rover  5  System  from  L3  Communications  provides  long 
range  high  bandwidth  communication  that  may  enable 
relay  between  disconnected  cell  networks.  Lockheed 
Martin's  Combat  Edge  System  seeks  to  achieve  interop¬ 
erability  with  current  command  and  control  capabili¬ 
ties.  Significant  work  is  being  done  across  the  board  to 
develop  command  and  control  apps  for  Smartphones. 
While  the  proposed  architecture  has  not  confronted  ev¬ 
ery  challenging  issue,  it  is  a  feasible  start  point  for  seri¬ 
ous  test  and  evaluation  and  future  development. 


lrThe  listing  of  commercial  technologies  in  this  report  is  only  meant 
to  suggest  the  availability  of  these  capabilities  in  the  commercial  sec¬ 
tor.  We  do  not  endorse  any  one  of  these  technologies  over  their  com¬ 
petitors,  and  we  have  not  conducted  and  tests  or  evaluations  of  their 
capabilities. 
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6  Modeling  and  Simulation 

Three  types  of  modeling  and  simulation  were  con¬ 
ducted  to  test  the  feasibility  of  the  proposed  architec¬ 
ture  and  to  compare  its  performance  to  existing  or  pro¬ 
posed  systems.  The  first  type  of  modeling  was  a  web- 
based  tool  for  static  propagation  modeling.  This  al¬ 
lowed  the  design  team  to  play  with  system  parameters 
in  the  context  of  an  actual  use  scenario.  The  second  type 
was  a  dynamic  communications  model  that  allowed  an 
entire  scenario  of  communications  to  be  calculated  as 
units  moved  over  time.  The  final  scenario  was  a  combat 
simulation  with  a  communications  model  in  the  loop 
to  calculate  propagation.  The  combat  simulation  also 
included  a  prototype  Smartphone  loaded  with  C2  soft¬ 
ware  that  interfaced  with  the  simulation  environment. 

6.1  Scenario 

A  dismounted  engineer  platoon  is  conducting  civil  af¬ 
fairs  operations  in  Khowst  Afghanistan,  shown  in  Fig¬ 
ure  8.  They  are  going  to  a  village  meeting  with  the  el¬ 
ders  in  vicinity  of  Objective  Raven.  They  will  travel  to 
this  location  via  Route  Thunder,  Route  Lightning,  and 
Route  Flash.  They  proceed  down  Route  Thunder  and 
dismount  when  they  arrive  at  Route  Lightning.  While 
on  patrol  on  Route  Lightning  they  receive  small  arms 
fire.  They  call  back  to  the  MRAP  which  is  at  the  inter¬ 
section  of  Thunder  and  Lightning.  The  soldiers  at  the 
MRAP  send  a  raven  (a  company  size  UAV  asset).  With 
the  UAV  they  see  the  enemy  size  and  location.  They  then 
call  up  an  Apache  who  is  working  in  their  section.  They 
quickly  tell  the  Apache  size  and  location  of  enemy.  The 
Apache  makes  its  run  and  destroys  the  enemy.  With  vi¬ 
sual  from  the  Raven  the  platoon  can  see  that  the  enemy 
has  been  neutralized.  They  continue  the  mission  and 
arrive  in  the  village  to  meet  with  the  elders.  Following 
the  meeting  they  return  to  their  forward  operating  base 
(FOB). 

6.2  Static  Communications  Modeling 

The  design  team  used  an  on  line  radio  propagation 
model  called  CLOUDRF  to  get  initial  estimates  of 


Figure  8:  Modeling  Scenario. 


the  ranges  of  the  alternative  systems  (CLOUDRF.COM, 
2011).  The  advantage  of  this  model  was  its  ease  of  use 
and  intuitive  interface.  This  allowed  the  team  to  un¬ 
derstand  the  implications  of  frequency,  antenna  height, 
power,  and  terrain  on  radio  propagation.  They  built  a 
series  of  CLOUDRF  scenarios  that  captured  the  differ¬ 
ence  between  the  cell  system  and  the  SINCGARS  radio. 
Figure  9  shows  the  coverage  that  a  cell  tower  on  the  base 
would  have.  While  coverage  in  some  places  is  out  to  be¬ 
yond  15km,  a  large  hill  in  the  scenario  prevents  coverage 
of  the  dismounted  avenue  of  approach.  Figure  10  shows 
the  coverage  a  vehicle  mounted  cell  tower  would  have 
from  the  dismount  point.  This  tower  would  allow  com¬ 
munications  along  the  entire  dismounted  route  and  re¬ 
lay  back  to  the  FOB.  Figure  11  shows  the  improved  cov¬ 
erage  for  a  SINCGARS  radio.  For  a  SINCGARS,  no  relay 
station  is  necessary. 

6.3  Dynamic  Communications  Modeling 

COMPOSER  is  a  Communications  Planner  for  Oper¬ 
ational  and  Simulation  Effects  with  Realism.  Essen- 


10 


6  MODELING  AND  SIMULATION 


Ligure  9:  Coverage  for  cell  tower  on  the  LOB.  All  areas 
but  the  purple  and  gray  areas  can  be  covered  from  the 
base.  Note  the  hilltop  north  of  the  base  blocks  the  dis¬ 
mounted  avenue  of  approach  used  for  the  scenario. 
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Ligure  10:  Coverage  for  the  dismount  point.  Bringing  a 
vehicle  based  cell  tower  to  the  dismount  point  enables 
coverage  of  the  entire  dismounted  avenue  of  approach. 
The  vehicle  tower  can  relay  traffic  back  to  the  base. 


RF  coverage  -  advanced 
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Ligure  11:  Coverage  for  a  SINCGARS  radio  using  a  40 
foot  antenna  at  the  base.  Because  of  its  lower  frequency 
and  high  power,  the  SINCGARS  radio  can  cover  the  en¬ 
tire  operation  from  the  LOB. 

daily  what  this  means  is  that  scenarios  or  troop  move¬ 
ments  can  be  input  into  COMPOSER  along  with  ter¬ 
rain  data  from  basically  anywhere  in  the  world.  In  ad¬ 
dition,  COMPOSER  will  map  the  connectivity  of  up  to 
2000  radio  nodes  in  six  hundred  times  faster  than  real 
time.  All  of  these  elements  combined  allow  COMPOSER 
to  model  military  movements  on  realistic  terrain  with 
the  characteristics  of  their  radios.  This  helps  account 
for  factors  that  cannot  be  accounted  for  in  other  sim¬ 
ulations,  such  as  dead  space  due  to  mountainous  ter¬ 
rain.  COMPOSER  also  reports  over  7  types  of  commu¬ 
nications  traffic  flows  in  one  simulation.  The  benefit  is 
that  COMPOSER  is  capable  of  identifying  potential  net¬ 
work  problems  before  they  become  a  problem  in  reality. 
It  can  also  help  screen  out  candidate  solution  technolo¬ 
gies  before  any  money  is  invested  in  them. 

The  design  team  used  COMPOSER  to  model  the  sce¬ 
nario  shown  in  Figure  8.  For  that  scenario,  COMPOSER 
analyzed  three  different  radio  types:  Cell  phones,  SINC¬ 
GARS,  and  JTRS  (Representative  of  Nett  Warrior).  Each 
of  these  radio  types  was  simulated  twice.  The  first  simu¬ 
lation  for  each  involved  a  base  radio  (tower)  at  COP  Bear 
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Figure  12:  Screen  shot  of  COMPOSER  3-dimensional 
playback  for  Khowst  scenario. 


and  one  radio  for  the  main  effort  that  moves  to  Objec¬ 
tive  Raven  by  traveling  north,  around  the  back  of  the  hill 
which  Objective  Raven  sits  upon,  and  up  the  backside 
of  that  hill  to  the  Objective.  The  simulation  for  each  ra¬ 
dio  type  involved  both  of  the  aforementioned  entities  as 
well  as  a  relay  entity.  This  relay  entity  had  a  radio  with 
the  same  parameters  as  the  main  effort  radio.  It  trav¬ 
els  with  the  main  effort  until  reaching  the  east  side  of 
hill  where  the  main  effort  dismounts.  At  that  point  it 
stops  and  is  able  to  relay  messages  from  the  main  effort 
back  to  the  FOB.  COMPOSER  provided  us  with  a  large 
amount  of  data  that  contributed  to  some  of  our  value 
functions.  An  example  is  the  value  measure  “comple¬ 
tion  rate.”  A  full  list  of  the  output  provided  by  COM¬ 
POSER  for  all  six  simulations  can  be  found  in  Figure  13. 
Note  that  the  cell  tower  system  needed  a  relay  in  order 
to  achieve  performance  on  par  with  the  SINCGARS  ra¬ 
dio.  The  JTRS  radio  outperformed  both  systems  with  re¬ 
spect  to  message  propagation. 

6.4  Integrated  Modeling  Environment 

The  final  simulation  aspect  of  this  project  was  to  archi¬ 
tect  an  integrated  simulation  environment  that  would 


allow  military  role  players  to  exercise  command  and 
control  over  a  combination  of  virtual  and  constructive 
forces  in  a  simulated  environment.  This  environment 
includes  an  immersive  environment  for  role  players, 
cell  phones  for  role  players  to  use  in  command  and  con¬ 
trol  and  situation  awareness,  and  constructive  forces 
for  OPFOR  and  for  those  forces  not  represented  by  role 
players.  An  important  distinction  between  this  envi¬ 
ronment  and  other  virtual  /constructive  environments 
is  the  integration  of  a  communications  effects  model 
that  allows  or  restricts  communications  traffic  based  on 
the  overall  capabilities  of  the  cell  network,  given  the  de¬ 
mand  it  sees.  Another  distinction  is  the  capability  to 
pass  orders  to  constructive  forces  using  the  cell  phone. 
The  advantage  of  this  environment  is  that  it  will  allow  a 
small  unit  to  simulate  the  command  and  control  effec¬ 
tiveness  of  different  cellular  architectures  without  hav¬ 
ing  to  actually  build  the  system.  This  simulation  archi¬ 
tecture  is  shown  in  Figure  14.  The  yellow  boxes  rep¬ 
resent  existing  systems,  and  the  green  boxes  represent 
systems  or  data  models  that  were  developed  or  modi¬ 
fied  within  this  project.  We  will  discuss  each  of  these 
items  further. 


6.4. 1  Existing  Simulation  Systems 

The  simulation  capabilities  developed  for  this  project 
take  advantage  of  existing  Army  simulation  systems. 
The  new  capabilities  are  meant  to  integrate  and  en¬ 
hance  existing  systems,  not  to  compete  with  them  or  re¬ 
place  them.  Referring  to  Figure  14,  the  MATREX  feder¬ 
ates  and  simulation  environment  are  used  throughout 
the  Army’s  Training  and  Doctrine  Command  (TRADOC) 
and  Research  Development  and  Engineering  Command 
(RDECOM)  for  experimentation  with  future  capabilities 
(Hurt  et  al.,  2006).  Program  Executive  Office  -  Soldier, 
the  West  Point  Department  of  Systems  Engineering,  and 
the  Virginia  Modeling  Analysis  and  Simulation  Center 
have  been  working  over  the  last  several  years  to  add  dis¬ 
mounted  command  and  control  capabilities  to  this  fed¬ 
eration  (Kewley  and  Tolk,  2009).  Another  existing  capa¬ 
bility  is  the  Army’s  Virtual  Battlespace  2  (VBS2)  virtual 
training  simulation  system  (Program  Executive  Office 
Simulation,  Training,  and  Instrumentation,  2011).  This 
system  allows  participants  to  become  virtual  players  on 
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Ligure  13:  COMPOSER  Results. 


the  battlefield,  integrating  with  the  constructive  entities 
from  the  MATREX  environment.  Finally,  a  Smartphone, 
tablet,  or  PC  can  connect  to  the  local  cellular  network, 
or  a  local  wireless  network,  and  integrate  with  the  simu¬ 
lation  environment  by  exchanging  data  with  the  CBMS 
Server  and  the  NVL  Toolkit  video  server.  The  human 
role  player  can  interact  with  the  environment  via  VBS2 
and  interact  with  the  command  and  control  and  situa¬ 
tion  awareness  systems  using  a  Smartphone. 

6.4.2  COMPOSER-MATREX  Interface 

As  part  of  this  project,  the  West  Point  Department  of 
Systems  Engineering  worked  closely  with  RDECOM’s 
MATREX  program  and  COMPOSER  programs  to  de¬ 
velop  an  interface  that  computed  communications  ef¬ 
fects  for  messages  sent  between  entities  in  the  MATREX 
environment.  This  integration  provides  a  command 
and  control  modeling  capability  that  is  a  significant  im¬ 
provement  for  the  Army’s  MATREX  environment  (US 
Army  Research,  Development  and  Engineering  Com¬ 
mand,  2010).  Previous  communications  effects  integra¬ 
tions  used  high  resolution  and  proprietary  communica¬ 
tions  models  that  introduced  a  high  computing  cost  and 


license  fee  for  MATREX  experiments.  The  COMPOSER 
integration  allowed  one  computer  to  manage  commu¬ 
nications  effects  in  a  platoon  sized  scenario.  COM¬ 
POSER  is  a  government  owned  system  with  no  licensing 
costs.  It  calculates  communications  message  comple¬ 
tion  and  delays  taking  into  account  radio  characteris¬ 
tics,  terrain,  and  network  loading  from  other  systems.  In 
addition,  the  project  team  developed  a  tool  to  initialize 
COMPOSER  using  data  from  the  Military  Scenario  De¬ 
scription  Language  that  is  also  used  to  initialize  the  MA¬ 
TREX  federation.  At  the  end  of  this  project,  this  capabil¬ 
ity  has  been  developed  and  tested  in  a  small  scenario  as 
a  proof  of  concept.  Additional  testing  and  development 
would  be  needed  for  a  large  scale  experiment. 


6.4.3  CBMS  Server 

As  part  of  this  project,  the  West  Point  Department  of 
Systems  Engineering  worked  closely  with  the  Virginia 
Modeling  Analysis  and  Simulation  Center  (VMASC), 
foint  Forces  Command  19,  and  the  French  Military 
Academy  at  St.  Cyr  to  enhance  the  Coalition  Battle  Man¬ 
agement  Language  and  associated  services  to  support 
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Figure  14:  Systems  View-1  Resource  Interaction  Specification  for  an  integrated  simulation  environment  for  the 
experimentation  and  evaluation  of  alternative  cellular  command  and  control  architectures. 


14 


6  MODELING  AND  SIMULATION 


dismounted  operations.  Of  particular  interest  is  the 
ability  to  pass  dismounted  orders.  The  results  of  this 
work,  described  in  detail  in  Section  7,  allow  virtual  role 
players  with  Smartphones  to  pass  orders  to  construc¬ 
tive  MATREX  entities  in  OneSAE  for  automatic  execu¬ 
tion.  This  eliminates  the  need  for  human  “pucksters” 
to  interpret  the  orders  and  enter  them  into  OneSAF’s 
user  interface.  The  advantage  of  this  integration  is  that 
role  players  with  Smartphones  can  use  the  phones  to 
gain  situational  awareness  and  immediately  issue  or¬ 
ders  with  those  phones  to  take  advantage  of  the  in¬ 
creased  information. 

6.4.4  MATREX- CBML  Situation  Awareness  Tool 

In  order  to  pass  situation  awareness  to  Smartphone 
users  via  CBMS,  and  interface  was  created  to  translate 
situation  awareness  messages  from  the  MATREX  envi¬ 
ronment  to  CBML  reports.  This  interface  queries  the 
MATREX  Situation  Awareness  and  Display  (SANDS2) 
service  for  the  local  operating  picture  of  any  friendly  en¬ 
tity.  SANDS2  responds  with  a  combination  of  MATREX 
SaluteReports  and  SituationReports.  These  are  con¬ 
verted  to  CBML  EntityStatusReports,  EntityLocationRe- 
ports,  and  EntityHostilityReports.  These  are  passed  to 
the  CBML  server  and  made  available  to  command  and 
control  systems  (Smartphones,  tablets,  or  PC’s)  that  re¬ 
quest  this  information.  Since  the  information  is  coming 
from  the  MATREX  environment  with  communications 
effects  integrated,  each  role  player  will  only  see  the  in¬ 
formation  that  was  passed  to  him  or  her  based  on  the 
capabilities  of  the  cellular  network. 

6.4.5  CBML  Battle  Command  System 

One  of  the  advantages  of  Smartphones  is  the  ease  with 
which  new  applications  can  be  developed.  In  order  for 
the  architecture  described  here  to  work,  an  Android  app 
needed  to  be  developed  that  would  allow  role  players  to 
read  situation  awareness  and  issue  tactical  orders  from 
their  Smartphones.  The  West  Point  Department  of  Sys¬ 
tems  Engineering  developed  a  prototype  capability  that 
could  perform  these  tasks  in  a  limited  fashion.  Only  a 
small  subset  of  the  tactical  orders  addressed  in  Section 
7  were  programmed  into  the  phone. 


Figure  15:  Situation  awareness  display  on  Android 
Smartphone. 

The  first  capability  programmed  was  a  situation  aware¬ 
ness  display,  seen  in  Figure  15.  This  display  uses  a 
Google  Maps  image  as  a  background  to  display  icons 
that  represent  friendly  and  enemy  forces.  The  gray 
circular  posts  represent  dismounts,  while  square  posts 
represent  vehicles.  The  white  dots  on  on  the  left  side 
of  the  screen  represent  activity  that  has  been  reported 
but  not  yet  confirmed  as  enemy.  In  addition,  the  user 
can  zoom  in  and  select  any  icon  to  get  additional  infor¬ 
mation  about  that  entity  as  it  has  been  reported.  This 
information  is  displayed  in  the  text  box  at  the  bottom  of 
the  screen.  After  viewing  this  situation  awareness  infor¬ 
mation,  the  user  can  select  the  Frago  button  to  issue  a 
fragmentary  order  to  a  subordinate  unit  for  execution. 

After  selecting  the  Frago  button,  the  user  is  presented 
with  a  menu  of  orders  that  can  be  given  to  subordi¬ 
nate  units,  as  shown  in  Figure  16.  For  example,  the  user 
could  select  ‘Advance  along  a  new  route”  and  be  pre¬ 
sented  with  the  interface  in  Figure  17.  This  interface  al¬ 
lows  him  or  her  to  designate  the  route  and  waypoints. 
A  subsequent  menu  can  assign  a  movement  technique 
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Figure  16:  List  of  possible  fragmentary  orders  that  can 
be  given  to  a  unit  via  the  Android  Smartphone  interface. 

and  formation. 

7  Coalition  Battle  Management 
Language  Extensions  for  Simula¬ 
tion  Interoperability 

This  section  addresses  the  challenge  of  simulation  and 
command  and  control  interoperability  for  coalition 
forces.  The  Coalition  Battle  Management  Language 
(CBML)  is  extended  and  harmonized  with  a  simulation 
command  and  control  data  model,  Primitives  of  Mean¬ 
ing  (POM),  using  a  Model  Based  Data  Engineering  Ap¬ 
proach  (MBDE).  This  yields  a  series  of  extensions  to 
CBML.  The  first  group  of  extensions  allows  execution  of 
low-level  tactical  tasks  such  as  mount  a  vehicle  or  orient 
in  a  particular  direction.  Additional  extensions  allow 
the  specification  of  detailed  execution  instructions  such 
as  the  speed  and  formation  for  movement  or  the  pos¬ 
ture  (kneeling,  prone,  standing,  etc.)  for  dismounted 


Figure  17:  Android  interface  to  order  a  unit  to  move 
along  a  new  route. 

forces.  The  last  extension  allowed  CBML  orders  to  be 
executed  by  a  person  or  a  unit,  as  opposed  to  only  by 
a  unit.  Using  these  extensions,  a  data  translator  devel¬ 
oped  in  this  work  is  able  to  receive  a  CBML  order  and  is¬ 
sue  it  as  a  POM  order.  Using  the  US  Army’s  Modeling  Ar¬ 
chitecture  for  Testing,  Research,  and  Experimentation 
(MATREX),  the  POM  order  was  autonomously  issued  as 
a  high  level  architecture  (HLA)  interaction  for  execu¬ 
tion  in  the  Army’s  One  Semi- Automated  Forces  (One- 
SAF)  combat  simulation.  In  this  manner,  the  simulation 
executed  the  CBML  order  issued  by  the  command  and 
control  system  directly,  without  any  additional  human 
interaction. 

Coalition  partners  do  not  execute  tactical  missions  the 
same  way.  Every  army  accomplishes  a  mission  accord¬ 
ing  to  its  national  doctrine  and  its  own  field  manu¬ 
als.  A  good  example  of  this  is  the  comparison  between 
an  ambush  organized  by  a  French  platoon  of  the  Ar- 
mee  de  Terre  and  an  ambush  organized  by  an  Amer¬ 
ican  platoon  of  the  U.S  Army.  According  to  U.S.  doc¬ 
trine  and  the  French  doctrine  de  Saint- Cyr  Coetquidan 
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Direction  de  la  Formation  Militaires  (2010);  Headquar¬ 
ters  Department  of  the  Army  (2007),  the  preparation 
and  the  first  phase  of  the  execution  of  an  ambush  are 
quite  the  same  in  both  cases:  the  platoon  is  divided  into 
three  elements,  with  precise  tasks  assigned  to  each  el¬ 
ement.  One  of  these  elements  is  in  charge  of  detect¬ 
ing  the  enemy’s  approach  and  providing  security:  it  is 
the  security  element  in  the  U.S.  doctrine  or  the  guet- 
alerte/couverture/recueil  in  the  French  doctrine.  More¬ 
over,  the  two  remaining  elements  have  to  destroy  the 
enemy  forces.  In  order  to  do  it,  the  first  of  these  two 
elements  has  to  provide  a  primary  killing  power  to  fix 
the  enemy  into  the  kill  zone:  it  is  the  support  element 
or  the  arret  in  French.  Finally,  once  the  enemy  forces 
are  isolated  and  fixed  in  the  kill  zone,  the  last  element 
is  therefore  able  to  deliver  a  large  volume  of  highly  con¬ 
centrated  fire  into  the  kill  zone  in  order  to  kill  and  de¬ 
stroy  as  many  enemy  soldiers  and  vehicles  as  possible. 
This  last  element  is  called  assault  element  or  destruc¬ 
tion. 

However,  the  second  phase  of  the  execution  of  an  am¬ 
bush  is  very  different  between  French  Doctrine  and  U.S. 
Doctrine.  Indeed,  once  the  two  elements  in  charge  of 
destroying  the  enemy  forces  have  brought  the  kill  zone 
under  concentrated  fire,  the  French  troops  have  to  with¬ 
draw  immediately,  in  order  to  prevent  any  enemy  rein¬ 
forcement  from  having  the  time  to  reach  the  ambush 
site.  On  the  contrary,  after  this  first  phase  of  delivering  a 
large  volume  of  fire,  the  U.S.  platoon  leader  may  assault 
the  kill  zone  with  the  assault  element,  in  order  to  clear 
and  search  the  area  entirely  and  to  gather  intelligence. 

Consider  a  company  deployed  in  a  multinational  the¬ 
atre  and  composed  of  both  French  and  American  pla¬ 
toons.  Imagine  that  the  company  commander  is  French 
and  wants  his  American  platoon  to  organize  an  am¬ 
bush,  and  imagine  his  surprise  and  his  worries  in  terms 
of  timeline  and  security  when  he  sees  the  American  pla¬ 
toon  assaulting  the  kill  zone  of  the  ambush  site  whereas 
he  was  expecting  them  to  withdraw. 

7. 1  Primitives  of  Meaning 

In  the  previous  example,  it  would  be  very  difficult  for  US 
and  French  forces  to  interoperate  with  a  common  un¬ 


derstanding  of  the  doctrinal  task  “ambush.”  Doing  so 
would  require  a  common  understanding  of  the  steps  of 
an  ambush,  and  one  country  or  the  other  would  have 
to  do  significant  restructuring  of  doctrinal  manuals  and 
retraining  to  support  the  agreed  upon  standard.  How¬ 
ever,  if  we  decompose  the  mission  term  “ambush”  into 
the  very  basic  tasks  that  the  platoon  has  to  execute  at 
the  lowest  levels,  squads  and  even  soldiers,  we  can  ex¬ 
press  both  French  and  US  ambushes  using  these  sim¬ 
ple  primitives.  This  is  the  principle  of  the  POM:  decom¬ 
posing  every  military  operation  involving  small  infantry 
units  into  elemental  concepts  to  prevent  ambiguity  be¬ 
tween  units.  In  this  way,  “interoperability  between  sys¬ 
tems  is  enabled  by  the  transmission  of  communications 
from  a  transmitting  system  to  a  receiving  system,  and 
the  interpretation  of  those  communications  by  the  re¬ 
ceiving  system  Kewley  et  al.  (2010).”  In  its  current  state, 
POM  decomposes  dismounted  military  operations  into 
the  following: 

Move  Moves  an  individual  along  a  route.  The  end 
point  of  the  route  is  the  destination.  Includes  a 
movement  speed  and  an  optional  elevation  above 
ground  level  for  aircraft. 

Patrol  Similar  to  move,  but  upon  completion  of  the 
route,  the  entity  returns  to  the  start  point  and  cir¬ 
cles  continuously. 

SetWeaponsControlStatus  Sets  an  entity’s  weapons 
control  status  to  Free,  Tight,  or  Hold,  optionally  for 
a  specific  area  of  the  battlefield. 

Orient  Orients  an  entity  in  a  specific  compass  direc¬ 
tion. 

Fire  Orders  an  entity  to  fire  a  certain  percentage  of  its 
magazine  an  engagement  area.  This  is  useful  for 
suppressive  fires. 

SetPosture  Orders  a  dismounted  entity  to  assume  one 
of  several  postures,  such  as  standing,  kneeling,  or 
prone. 

SetWeaponState  Orders  an  entity  to  stow  its  weapon, 
or  deploy  it  for  firing. 

Observe  Orders  an  entity  to  observe  a  specific  area  of 
the  battlefield. 
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Figure  18:  French  and  US  doctrine  for  an  ambush. 


SearchEntity  Orders  an  entity  to  search  another 
named  entity.  This  is  useful  for  searching  de¬ 
tainees  or  traffic  control  point  operations. 

Mount/Dismount  Orders  a  dismounted  entity  to 
mount  or  dismount  a  vehicle. 

SearchArea  Orders  an  entity  to  search  a  specific  area 
of  the  battlefield.  This  is  useful  for  searching  for 
weapons  caches. 

SearchRoute  Orders  an  entity  to  search  along  a  specific 
route  looking  for  hidden  improvised  explosive  de¬ 
vices. 

SearchRoom  Orders  an  entity  to  search  a  specific 
room,  indicated  by  a  polygon  of  the  room  bound¬ 
aries.  This  is  useful  for  cordon  and  search  opera¬ 
tions. 

Halt  Orders  an  entity  to  stop  movement  immediately. 

SendSignal  Orders  an  entity  to  send  a  signal  to  another 
entity.  A  typical  use  of  this  field  is  to  signal  that 
an  entity  is  complete  with  the  assigned  order.  This 
supports  coordinated  actions  within  an  operation. 

ClearRoom  Orders  a  unit  to  clear  a  room. 


Using  these  primitives  of  meaning,  an  ambush  could  be 
described  more  accurately  in  either  French  or  US  doc¬ 
trine. 

1.  Move  primitives  given  to  assault,  support,  and  se¬ 
curity  forces  to  get  them  into  position  and  forma¬ 
tion. 

2.  Orient  primitives  given  to  all  forces  directing  their 
orientation. 

3.  Upon  identification  of  enemy  in  engagement  area, 
Fire  primitive  given  to  assault  force  and  support 
force  to  direct  fires  in  the  engagement  area. 

4.  In  US  doctrine  only}  SearchArea  primitive  given  to 
assault  force  to  search  engagement  area  for  useful 
intelligence. 

5.  Move  primitives  given  to  all  fores  to  direct  their 
with  drawl  from  the  ambush  area. 

This  structure  accurately  captures  either  the  French  or 
US  doctrine  for  an  ambush.  A  command  and  control 
system  implementing  these  primitives  could  give  an  un¬ 
ambiguous  ambush  order,  as  an  ordered  sequence  of 
primitives,  to  a  platoon  using  either  of  the  two  doc¬ 
trines. 


18 


7  COALITION  BATTLE  MANAGEMENT  LANGUAGE  EXTENSIONS  FOR  SIMULATION  INTEROPERABILITY 


7.2  Simulation  Services  as  Primitives  of 
Meaning 

In  order  to  be  able  to  see  the  execution  of  the  tasks 
represented  by  the  Primitives  of  Meaning  in  com¬ 
bat  simulations  the  MATREX  federation  object  model 
(FOM)Hurt  et  al.  (2006);  MATREX  (2009),  used  by  the  US 
Army’s  Research,  Development,  and  Engineering  Com¬ 
mand  to  federate  combat  models  across  engineering 
domains,  has  been  extended  by  adding  new  complex 
data  types  and  interactions  which  correspond  to  the 
primitives.  In  order  to  allow  sequences  of  actions  to  be 
simulated,  a  data  type  specifying  the  order  of  execution 
and  timing  for  each  action  has  also  been  added. 


7.3  Coalition  Battle  Management  Language 

The  Coalition  Battle  Management  Language  (CBML)  is 
a  language  using  XML- structured  documents  and  based 
upon  Joint  Consultation,  Command  and  Control  Infor¬ 
mation  Exchange  Data  Model’s  (JC3IEDM)  MIP-NATO 
Management  Board  (2009)  entities,  attributes  and  val¬ 
ues.  CBML  has  been  developed  to  reach  two  purposes: 
command  and  control  of  land,  naval  or  aerial  forces  par¬ 
ticipating  in  military  operations  and  improving  com¬ 
manders’  awareness  of  the  situation  on  the  battlefield 
[Need  CBML  Reference].  That  is  why  CBML  is  struc¬ 
tured  in  Orders,  Reports  and  Requests. 

CBML  is  much  closer  to  the  POM’s  structure  than  the 
JC3IEDM.  Each  mission  in  CBML  is  described  by  a  se¬ 
quence  of  tasks  that  it  is  possible  to  order  in  accordance 
to  the  execution  of  the  mission.  In  addition,  each  task  in 
CBML  is  organized  into  several  elements  of  information 
which  enable  the  CBML  structure  to  describe  precisely 
the  way  the  task  has  to  be  executed. 

However,  CBML  is  composed  of  mission  terms  and  in¬ 
formation  elements  better  suited  for  the  operational 
level  of  war  -  moving  large  forces  on  the  battlefield.  It 
cannot  describe  basic  tasks  such  as  postures,  forma¬ 
tions  and  ammo  consumption.  That  is  why  CBML  can¬ 
not  be  directly  translated  into  POM  and  needs  to  be  ex¬ 
tended.  Those  extensions  will  be  made  following  the 
Model-Based  Data  Engineering  methodology. 


7.4  Model-Based  Data  Engineering 
Methodology 

Model-Based  Data  Engineering  is  a  methodology  which 
aims  at  enabling  the  exchange  of  data  elements  be¬ 
tween  heterogeneous  systems,  by  mapping  equivalent 
information  expressions  from  each  system  to  a  com¬ 
mon  reference  model  Tolk  and  Diallo  (2005).  It  is  com¬ 
posed  of  four  processes:  data  administration,  data  man¬ 
agement,  data  alignment  and  data  transformation. 

In  our  case,  we  chose  the  POM  as  the  reference  model 
for  two  reasons.  First,  POM  contains  data  structures 
with  the  highest  granularity.  Second,  the  primitives  can 
describe  a  missions  at  the  tactical  level  due  to  the  in¬ 
clusion  of  tactical  tasks  in  the  primitives..  CBML  is  bet¬ 
ter  suited  for  higher  level  operations,  lacking  the  de¬ 
tails  needed  for  tactical  missions  at  the  company  level 
and  below.  That  is  why  using  the  POM  as  the  reference 
model  and  extending  CBML  would  enable  CBML  to  be 
also  used  as  a  tactical  level  command  and  control  tool, 
in  addition  to  its  current  capabilities. 

7.4.1  Data  Administration 

The  steps  of  data  administration  were  relatively  easy. 
CBML  and  POM  specifications  were  each  defined  in 
XML  schemas  with  validated  examples  available  for 
each  case.  This  common  feature  allowed  the  following 
steps  to  all  be  performed  with  available  XML  tools. 

7.4.2  Data  Management 

After  having  achieved  the  data  administration  phase, 
the  second  process  that  we  find  in  the  Data  Engineer¬ 
ing  methodology  is  data  management.  This  phase  is  the 
most  important  one  in  the  Data  Engineering  chain.  This 
process  “identifies  and  describes  data  elements,  and 
maps  equivalent  information  expressions  to  each  other 
Tolk  and  Diallo  (2005).”  In  the  case  of  XML-based  struc¬ 
tures,  the  main  purpose  of  data  management  is,  there¬ 
fore,  to  solve  formative  and  semantic  tag- set  conflicts 
between  the  participating  systems.  These  conflicts  are 
divided  into  four  different  classes:  semantic,  descrip¬ 
tive,  heterogeneous,  and  structural  conflicts: 
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Semantic  conflicts  occur  when  local  schemata  con¬ 
cepts  must  be  aggregated  or  disaggregated,  but  fail 
to  exactly  match  (they  might  overlap  or  be  subsets 
of  each  other,  for  example). 

Descriptive  conflicts  occur  when  the  same  concept  is 
described  using  homonyms,  synonyms,  or  differ¬ 
ent  names,  attributes,  slot  values,  and  so  on. 

Heterogeneous  conflicts  occur  when  concepts  are  de¬ 
scribed  using  substantially  different  methodolo¬ 
gies. 

Structural  conflicts  occur  when  the  same  concept  is 
described  using  different  structures  Tolk  and  Diallo 
(2005). 

We  dealt  each  of  these  conflict  types  in  the  data  man¬ 
agement  process. 

While  CBML  is  able  to  provide  both  orders  and  infor¬ 
mation  about  the  commander’s  situation  awareness,  it 
cannot  describe  the  basic  tasks  that  soldiers  have  to  ex¬ 
ecute  at  the  lowest  military  levels  (e.g.  changing  for¬ 
mation,  posture  or  deciding  precise  ammo  consump¬ 
tion).  Therefore,  these  differences  also  imply  heteroge¬ 
neous  conflicts.  CBML  is  adapted  to  operational  level 
missions  (regiments,  brigades  and  higher),  whereas  the 
methodology  of  the  primitives  is  adapted  to  tactical 
level  missions  (companies,  platoons  and  lower).  In  or¬ 
der  to  solve  this  conflict,  we  had  to  make  a  choice  be¬ 
tween  two  solutions.  First,  we  could  unpack  the  CBML 
high  level  mission  terms  by  describing  the  execution  of 
each  CBML  task  with  a  sequence  of  POM.  However,  this 
solution  would  require  us  to  make  assumptions  about 
what  primitives  each  CBML  action-task- activity- code 
implies.  In  addition,  to  keep  those  assumptions  reli¬ 
able  to  ensure  the  exchanged  data’s  credibility  and  fi¬ 
delity,  we  would  have  to  match  a  precise  doctrine  and, 
therefore,  add  a  new  entity  “DOCTRINE”  to  CBML  and 
JC3IEDM.  Articulating  a  common  doctrine  in  CBML  for 
the  detailed  execution  of  high-level  tasks  would  be  dif¬ 
ficult. 

That  is  why  we  chose  to  focus  on  another  solution. 
Considering  the  POM  as  the  reference  in  our  MBDE 
methodology,  adding  extensions  to  the  CBML  data 
model,  in  order  to  support  the  basic  tasks  that  soldiers 


have  to  execute  on  the  battlefield,  would  allow  us  to  be 
find  equivalent  information  expressions  to  the  primi¬ 
tives.  This  solution  had  three  advantages.  First  of  all, 
adding  those  extensions  would  provide  CBML  with  the 
capability  of  being  used  as  a  low  level  command  and 
control  tool  for  tactical  operations.  Moreover,  this  solu¬ 
tion  should  be  easier  to  implement,  because  we  would 
not  have  to  integrate  a  common  doctrine  into  CBML 
and  JC3IEDM,  with  all  the  associations  management 
such  a  process  implies.  But  above  all,  we  would  not 
need  to  make  assumptions  to  translate  CBML  into  the 
primitives  with  this  solution,  making  the  data  mapping 
process  much  more  accurate  and  efficient.  This  in¬ 
tellectual  process  achieved  “conceptual  mapping”  by 
agreeing  “on  the  data  models’  conceptual  correspon¬ 
dence  Tolk  and  Diallo  (2005)  ”  and  working  to  preserve 
the  original  design  intent  of  each  model. 

The  attribute  mapping  step  of  data  management  calls 
for  an  agreement  on  which  attributes  reflect  identical 
concepts  on  each  side.  For  every  single  attribute  of  our 
POM  reference  model,  we  tried  to  find  an  equivalent  el¬ 
ement  of  information  among  the  CBML  attributes  and 
values.  The  result  is  shown  in  Figure  19. 

Among  the  twenty- five  different  attributes  for  the  POM, 
only  seven  need  extensions  in  CBML.  This  reflects  our 
goal  to  have  a  solution  implying  as  few  extensions  as 
possible,  in  order  to  have  the  highest  natural  inter¬ 
operability  between  the  primitives  and  CBML.  How¬ 
ever,  this  table  also  points  out  some  descriptive  and 
semantic  conflicts.  For  example,  the  primitive  Fire 
corresponds  to  the  action -task- activity- code  ENGAGE 
in  CBML.  Semantic  conflicts  happen  when  data  in¬ 
formation  concepts  need  to  be  “aggregated  or  disag¬ 
gregated,  but  fail  to  exactly  match.”  This  is  the  case 
with  the  CBML  attributes  action-task- start- qualifier- 
code  and  action- start-temporal- association- category- 
code  as  they  translate  to  ActionTrigger  in  order  to  rep¬ 
resent  AfterDelay.  This  will  have  to  be  handled  in  a  the 
data  transformation  process. 

7.4.3  Data  Alignment 

We  added  four  types  of  extension  during  data  align¬ 
ment  to  handle  the  conflicts  identified  during  data  ad- 
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Primitives  of  Meaning  (reference  data  model) 

CBML 

Move 

what-action-task-activity-code  value  MOVE  or  ADVANC 

1  -  ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

2  -  RouteGraphic 

where-derived-location-id 

3  -  MoveSpeed 

extension  needed  as  attribute 

4  -  AltMetersAGL 

0.0  (small  infantry  units  only) 

5  -  Formation 

extension  needed  as  attribute 

Patrol 

what-action-task-activity-code  value  PATROL 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

RouteGraphic 

where-derived-location-id 

MoveSpeed 

extension  needed  as  attribute 

AltMetersAGL 

0.0  (small  infantry  units  only) 

Formation 

extension  needed  as  attribute 

SetWeaponsControlStatus 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

6  -  WeaponsControlStatus 

current-state-report-organisation-status-fire-mode-code 

Orient 

extension  needed  as  what-action-task-activity-code  value 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

7  -  OrientationlnDegrees 

resource-employment-azimuth- fire-angle 

Fire 

what-action-task-activity-code  value  ENGAGE 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

8  -  EngagementArea 

affected- who-obi  et- item-id 

9  -  PercentOfMagazine 

extension  needed  as  attribute 

SetPosture 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

10  -  Posture 

extension  needed  as  attribute 

SetICWeaponState  or  SetWeaponState 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

11  &  12  -  ICWeaponState  or  WeaponState 

extension  needed  as  attribute  for  both 

Observe 

what-action-task-activity-code  value  OBSRV 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

1 3-  AreaOflnterestGraphic 

affected- who-ob]  et- item-id 

SearchEntity 

what-action-task-activity-code  value  SERCH 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

14  -  EntityToSearch 

where-derived-location-id 

Mount 

extension  needed  as  what-action-task-activity-code  value 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

1 5  -  VehicleToMount 

affected- who-ob]  et- item-id 

Dismount 

extension  needed  as  what-action-task-activity-code  value 

|  ActionTrigger 

|  when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

SearchArea 

what-action-task-activity-code  value  SERCH 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

1 6  -  SearchAreaGraphic 

where-derived-location-id 

1 7  -  DurationOfSearchlnSeconds 

when-action-task-maximum-duration 

SearchRoute 

what-action-task-activity-code  value  SERCH 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

RouteGraphic 

where-derived-location-id 

SearchRoom 

what-action-task-activity-code  value  SERCH 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

1 8  -  RoomGraphic 

where-derived-location-id 

Halt 

extension  needed  as  what-action-task-activity-code  value 

|  ActionTrigger 

|  when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

SendSignal 

extension  needed  as  what-action-task-activity-code  value 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

19  -  SendTo 

affected- who-obj  et- item-id 

20  -  Signal 

extension  needed  as  attribute 

2 1  -  MessageReveiverType 

affected- who-ob]  et- item-type 

22  -  MessageTransmissionType 

extension  needed  as  attribute 

ClearRoom 

what-action-task-activity-code  value  CLRLND  or  CAPTUR 

ActionTrigger 

when-action-task-start-qualifier-code  or  when-action-start-temporal-association-category-code 

23  -  StackLocation 

current-state-report-obiect-item-location 

24  -  StackLocation 

current-state-report-object-item-location 

RoomGraphic 

where-derived-location-id 

25  -  EntranceLocationGraphic 

where-derived-location-id 

UnitCommand 

taskee-who-organisation-ref  UnitRef  type 

SingleEntityCommand 

extention  needed  as  taskee-who-organisation-ref  type 
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Figure  19:  Attribute  mapping  for  CBML  and  POM. 
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ministration,  shown  in  Figure  19.  Five  new  action -task- 
activity- code -value  entries  were  added  for  the  five  miss¬ 
ing  tasks  mount,  dismount,  halt,  orient,  and  send  sig¬ 
nal.  Five  optional  fields  were  added  to  the  ACTION- 
RESOURCE-EMPLOYMENT  entity  to  handle  forma¬ 
tions,  movement  speed,  signal  text,  signal  type,  and  am¬ 
munition  expenditure.  Two  optional  fields  were  added 
to  ORGANISATION- STATUS  to  handle  weapon  state 
and  posture.  Finally,  taskee-who- organisation- typeref 
was  extended  by  adding  PersonRef  to  allow  CBML  to 
task  persons  in  addition  to  units.  Collectively,  these  ex¬ 
tensions  imposed  minimal  changes  to  CBML  and  did 
not  depart  from  the  original  intentions  of  the  modi¬ 
fied  elements  as  they  are  described  in  CBML  documen¬ 
tation  Simulation  Interoperability  Standards  Organiza¬ 
tion  (2010). 

7.4.4  Data  Transformation 

During  data  transformation  we  built  a  program  that 
would  transform  a  CBML  file  that  is  compliant  with  our 
extensions  to  a  POM  file.  During  content  mapping,  the 
translator  needed  to  define  the  mathematical  relation¬ 
ships  between  the  equivalent  attributes  defined  during 
data  administration.  While  most  of  the  transformations 
involved  moving  data  directly  from  a  CBML  attribute  to 
the  corresponding  POM  attribute,  two  particular  enti¬ 
ties  required  additional  effort. 

In  CBML,  a  phase,  a  task,  and  a  primitive  are  each  iden¬ 
tified  by  the  TASK  entity.  The  context  and  ordering  of 
tasks  enables  us  to  map  to  the  following  three  cases: 

•  If  the  Tasker  and  Taskee  of  the  Task  are  the  same 
(an  organisation  is  tasking  itself),  consider  the  task 
a  phase. 

•  Consider  each  successive  task  to  a  single  Taskee  to 
be  a  primitive. 

•  Aggregate  successive  primitives  to  a  single  Taskee 
into  a  task  to  be  executed  by  that  Taskee  during  the 
phase. 

In  CBML,  there  is  no  direct  way  to  represent  starting  a 
task  after  a  delay.  The  CBML  XML  tag- set  When  can 


have  three  types  of  child  elements:  AbsoluteTime,  Rel- 
ativeTime  and  AbsoluteRelativeTime.  The  child  Abso¬ 
luteTime  indicates  that  the  Task  has  to  be  executed  at 
a  precise  moment  of  the  mission,  reflected  by  an  abso¬ 
lute  date.  However,  the  child  RelativeTime  is  used  when 
the  execution  of  the  Task  depends  on  the  execution  of 
a  reference  Task.  This  is  appropriate  when  you  want  a 
Task  to  be  executed  after,  or  before,  the  end,  or  the  be¬ 
ginning,  of  another  reference  Task.  But  it  is  also  possi¬ 
ble  to  find  in  structure  of  CBML  the  child  AbsoluteRel¬ 
ativeTime  which  contains  all  the  properties  of  the  two 
previous  children  of  the  element  When.  AbsoluteRel¬ 
ativeTime  reflects  that  the  CBML  Task  has  to  be  exe¬ 
cuted  both  according  to  a  precise  date  and  depending 
on  another  reference  Task.  We  chose  to  translate  the 
element  AbsoluteRelativeTime  into  the  primitives’  Trig- 
gerType  “AfterDelay”  because  it  allowed  us  to  calculate 
the  delay  before  the  execution  of  the  Task  by  having  two 
dates  at  our  disposal:  one  reflecting  when  the  Task  that 
has  to  be  executed  and  one  belonging  to  the  reference 
Task.  By  performing  the  subtraction  between  the  date 
of  the  Task  and  the  reference  date,  we  get  the  value  of 
the  primitives’  attribute  DelaylnSeconds  corresponding 
to  the  TriggerType  ‘AfterDelay”. 


7.5  Tactical  Mission  Example 

In  order  to  exercise  the  coalition  and  simulation  inter¬ 
operability  enabled  by  our  research,  we  have  chosen  to 
represent  a  tactical  support  by  fire  mission  through  a 
French  OPORD,  and  we  want  to  be  able  to  see  the  ex¬ 
ecution  of  this  mission  into  the  simulation  tools  of  the 
U.S  Army.  Therefore,  our  goal  is  to  generate  a  CBML- 
compliant  XML  file  from  the  French  OPORD  with  our 
interface,  and  then  translate  this  CBML- compliant  doc¬ 
ument  into  an  XML  document  using  the  structure  POM, 
which  is  understandable  by  the  OneSAF  simulations 
thanks  to  the  extensions  made  to  the  MATREX  FOM. 

The  mission  of  the  1st  French  Platoon  in  Table  1  shown 
in  Figure  20  is  to  provide  support  by  fire  on  the  house 
named  Oscar  2,  from  the  wood  corner  named  Oscar  1. 
In  order  to  accomplish  this  mission,  the  1st  Platoon  has 
to  advance  to  Oscar  1  through  an  intersection  named 
Hotel  1,  where  the  squads  have  to  change  their  postures 
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Figure  20:  Tactical  graphic  for  French  OPORD. 


JE  VEUX:  Appliquer  des  feux  sur  I’ENI  situe  au  niveau  de  EA 
Oscar  1  a  compter  du  02  octobre  2010  a  06h30  pour  au  mieux 
detruire  au  pire  chasser  I’ENI  qui  I’occupe.  POUR  CELA  : 

Me  deplacer  en  ambiance  surete  jusqu’a  I’intersection  en 
32.3695  Q  N  84.8068  Q  O,  bapteme  terrain  Hotel  1,  puis  en 
ambiance  discretion  jusqu’a  la  corne  de  bois  en  32.3696  Q  N 
84.8045  Q  O,  bapteme  terrain  Oscar  1,  pour  y  installer  un 
dispositif  de  surveillance  et  d’appui  sur  EA  Oscar  1  pour  06h00. 

En  liaison  permanente  avec  le  2nd  PLT,  appliquer  des  feux  sur 
I’ENI  situe  au  niveau  de  EA  Oscar  1  a  compter  du  02  octobre 
2010  a  06h30. 

Me  renseigner  et  renseigner  la  compagnie  et  le  2nd  PLT  sur 
I’activite  ENI  dans  et  autour  EA  Oscar  1. 

EMD:  Mettre  en  place  un  dispositif  de  surveillance  face  au 
Nord  et  a  I’Est  a  partir  des  limites  Ouest  de  EA  Oscar  1  et  a 
compter  du  02  octobre  2010  06h35. 

Table  1:  Tactical  mission  described  by  French  OPORD 
and  tactical  graphic. 

to  reach  Oscar  1  in  a  stealth  mode.  Moreover,  the  Pla¬ 
toon  has  to  open  fire  at  6:30  AM,  in  order  that  the  2nd 
Platoon  can  capture  Oscar  2  for  no  later  than  6:45  AM. 
Finally,  once  the  1st  Platoon  has  brought  the  objective 
under  fire,  it  has  to  shift  its  fires  toward  North  and  East, 
in  order  to  prevent  any  enemy  forces  from  pulling  out 
of  the  house  or  reinforcing  OSCAR  2  from  vicinity  of  the 
objective  during  the  assault  of  the  2nd  Platoon. 


Through  a  CBML  command  and  control  user  interface 
we  developed  for  this  project,  we  expressed  the  OPORD 
in  a  CBML  compliant  structure  that  could  be  under¬ 
stood  and  read  into  any  other  C2  system  that  was  com¬ 
pliant  with  the  CBML  standard.  The  translator  read  the 
CBML  file  and  created  a  Primitives  of  Meaning  file  that 
could  be  sent  to  the  simulation  for  execution.  The  prim¬ 
itives  data  is  displayed  in  the  Primitives  of  Meaning  user 
interface  shown  in  Figure  21.  The  Primitives  of  Meaning 
GUI  translates  this  OPORD  into  a  set  of  MATREX  FOM 
interactions  that  can  be  read  by  OneSAF  and  executed 
as  shown  in  Figure  22. 

This  example  shows  the  capability  of  both  France  and 
the  United  States  to  take  part  in  simulated  multina¬ 
tional  exercises  with  the  POM  as  a  simulation  data 
model,  the  CBML  as  a  command  and  control  data 
model  which  matches  the  NATO  standard  JC3IEDM, 
and  with  our  translator  program  as  a  link  between  those 
two  data  models. 


7.6  Other  Potential  CBML  Extensions 

This  section  has  demonstrated  a  technical  approach 
and  sample  case  that  allows  a  CBML  compliant  com¬ 
mand  and  control  system  to  issue  an  operations  order 
for  direct  execution  by  a  simulation,  without  any  addi¬ 
tional  human  intervention.  This  capability  is  enabled 
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Figure  21:  POM  file  generated  by  translator  using  CBML 
compliant  expression  of  French  OPORD. 


by  the  concept  of  primitives  of  meaning,  the  expression 
of  low-level  tactical  actions  as  a  series  of  unambigu¬ 
ous  primitives  that  can  be  executed  by  coalition  forces 
or  by  the  simulation.  The  extensions  of  CBML  derived 
through  MBDE  allowed  CBML  to  handle  this  concept. 

While  this  effort  has  been  applied  to  the  dismounted  in¬ 
fantry  domain,  a  similar  approach  would  work  for  other 
domains.  In  the  air-to-air  combat  domain,  for  example, 
a  team  of  operational  experts  would  need  to  define  the 
necessary  primitives  that  can  be  ordered  by  air  forces 
engaged  in  air  to  air  combat.  They  would  need  to  ex¬ 
tend  CBML  using  a  similar  MBDE  approach  to  handle 
these  new  primitives.  They  would  also  need  to  build  the 
simulation  infrastructure  and  capability  to  receive  these 
primitives  and  react  accordingly.  Finally,  they  would 
need  to  extend  their  command  and  control  systems  to 
issue  orders  using  these  extensions.  Once  complete, 
coalition  partners  could  execute  a  joint  training  exer¬ 
cise  where  air  planners  from  each  partner  issued  air  or¬ 
ders  that  could  be  understood  by  their  partners  and  au¬ 
tomatically  executed  by  the  simulation. 


8  Analysis  and  Recommendations 


Figure  22:  Execution  of  French  OPORD  in  OneSAF. 


In  order  to  compare  our  alternatives,  a  combination  of 
system  properties,  simulation  results,  and  constructed 
scale  value  judgments  were  collected  in  a  raw  scoring 
data  matrix  for  each  alternative.  Each  element  of  raw 
data  is  scored  using  the  value  functions  in  ANNEX  B  in 
order  to  generate  value  scores  between  0  and  100  in  the 
value  matrix.  Each  value  score  is  multiplied  by  its  nor¬ 
malized  swing  weight,  shown  in  Figure  6,  to  generate 
the  additive  value  for  that  particular  evaluation  mea¬ 
sure. 

When  these  are  totaled,  we  get  the  total  value  model 
shown  in  Figure  23.  In  this  graphic,  the  total  value  for 
each  alternative  is  compared  to  an  ideal  solution,  which 
has  the  best  possible  score  for  all  value  measures,  and 
an  “All  Star”  solution,  which  combines  the  best  scores 
for  our  alternatives  into  one  solution.  These  compar¬ 
isons  not  only  show  which  of  the  alternatives  scores 
best,  but  also  how  each  alternative  could  potentially  be 
improved  to  return  more  value.  From  these  charts,  we 
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can  see  that  each  solution  has  its  strengths  and  weak¬ 
nesses.  The  SINCGARS  gets  high  scores  for  its  voice 
capabilities,  but  it  lacks  a  screen  for  video  or  situation 
awareness  displays.  It  is  also  fairly  heavy.  The  Nett  War¬ 
rior  offers  significant  improvement,  but  it  is  still  fairly 
heavy  with  limited  video  resolution.  The  Smartphone 
and  tablet  solutions  offer  the  greatest  total  value,  mostly 
due  to  their  ease  of  use  and  low  weight.  But  this  comes 
with  slightly  lower  transmission  ranges  and  some  secu¬ 
rity  risks. 

Additional  value  may  be  gained  by  engineering  in¬ 
creased  security  and  increased  radio  range  into  the  al¬ 
ternatives.  Some  of  this  is  represented  in  the  architec¬ 
ture  shown  in  Figure  7.  A  candidate  solution  provided 
by  Lockheed  Martin,  was  tested  in  the  CSDA  program 
with  mixed  results  (Army  Evaluation  Task  Force  AETF, 
2010).  The  test,  however,  did  demonstrate  the  feasibil¬ 
ity  of  a  cellular  solution  and  some  ability  to  engineer  in¬ 
creased  capabilities  into  the  system. 

Cost  comparison  between  alternatives  was  difficult  be¬ 
cause  each  system  was  in  a  different  stage  of  the  life  cy¬ 
cle.  In  the  case  of  programs  of  record,  unit  costs  de¬ 
pended  upon  order  quantity.  In  the  case  of  experimen¬ 
tal  systems,  vendor  cost  claims  can  be  misleading,  be¬ 
cause  all  requirements  are  not  engineered  into  the  pro¬ 
totypes.  However,  a  rough  order  of  magnitude  compar¬ 
ison  is  illustrative.  The  SINCGARS  (ASIP)  radio  is  by  far 
the  cheapest  system,  because  it  is  already  fielded.  The 
CSDA  program  provided  a  rough  order  of  magnitude 
cost  of  $2. 1  million  to  outfit  a  battalion  with  a  secure  cel¬ 
lular  network.  A  cost  estimate  on  the  Nett  Warrior  Sys¬ 
tem  is  about  $24,000  per  system.  If  the  Nett  Warrior  is 
used  down  to  squad  leader  level,  a  battalion  will  require 
81  systems  (aim,  2010),  yielding  a  total  cost  of  nearly  $2 
million.  If  the  basis  of  issue  is  down  to  the  team  leader 
level,  the  Nett  Warrior  cost  nearly  doubles  to  $3.7  mil¬ 
lion.  At  this  point,  the  commercial  cellular  solution  is 
less  expensive.  In  essence,  the  network  infrastructure 
is  the  primary  cost  driver  for  the  cellular  system.  Once 
the  infrastructure  is  in  place,  the  price  per  additional 
user  is  simply  the  price  of  a  commercial  cell  phone  and 
any  enhancements  to  that  phone  necessary  for  military 
operations.  Additionally,  since  software  development 
on  commercial  systems  is  typically  cheaper,  the  overall 
software  development  and  maintenance  prices  would 


be  cheaper.  A  similar  savings  would  be  had  for  train¬ 
ing,  due  to  the  ease  of  use  and  simplicity  of  commercial 
systems. 

Our  team  recommends  that  the  Army  test  and  evaluate 
a  commercial  cellular  architecture,  similar  to  the  one 
shown  in  Figure  7,  as  an  alternative  to  the  Nett  War¬ 
rior  system.  Our  analysis  shows  that  this  system  deliv¬ 
ers  more  value  to  the  stakeholders  at  potentially  half  the 
price.  Because  it  leverages  commercial  technology,  it 
will  have  the  added  advantage  of  easier  maintainability, 
upgrade -ability,  and  interoperability  with  partners  who 
also  use  commercial  technologies.  Prior  to  adoption, 
the  program  manager  must  integrate  security  consid¬ 
erations  and  increased  radio  range  into  the  overall  so¬ 
lution.  Some  potential  solutions  are  addressed  in  Sec¬ 
tion  5.  In  addition,  as  the  program  team  builds  battle 
command  applications,  we  recommend  they  consider 
adopting  NATO  standards  such  as  the  Coalition  Battle 
Management  Language  so  that  allied  partners  can  inte¬ 
grate  with  US  forces  who  use  this  architecture. 
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ANNEX  A  -  0V-5b  -  Operational  Activity  Models 


Figure  24:  Find  IED  Mission  Thread 


Figure  25:  MEDEVAC  Mission  Thread 
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Figure  26:  SITREP  Mission  Thread 


Figure  27:  Spot  Report  Mission  Thread 


Figure  28:  Call  for  Fire  Mission  Thread 
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Figure  29:  Video  Feed  Mission  Thread 


Figure  30:  Communicate  with  Adjacent  Units  Mission  Thread 
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Figure  31:  Track  Allied  Forces  Mission  Thread 


Figure  32:  Dismounted  Movement  Mission  Thread 
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ANNEX  B  -  System  Functions,  Objectives,  and  Value  Measures 


Figure  33:  System  functions,  objectives,  and  value  measures  for  text  and  voice  functions. 
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Figure  34:  System  functions,  objectives,  and  value  measures  for  report  friendly/ enemy  and  provide  visual  func¬ 
tions. 


1  Star-  Cannot  figure  out  how  to  use  because  it  is  impossible  to  use  and  have  no  idea 
h  to  do  anything  other  than  turn  it  on 

?  Stars-  Can  use  but  ineffective  because  I  cannot  figure  out  all  of  the  different 
>onents  to  It.  Unless  we  were  in  gamson  I  would  not  even  took  at  it 

3  Stars-  Average  difficulty  I  know  a  lot  of  the  features  and  how  to  use  them  but  still 
y  a  lltlle  bit  when  trying  to  use  everything 

\  Stars-  Can  use  effectively  I  know  how  to  use  a  lot  of  the  features  and  can  do  so 
vely  quickly 

5  Stars-  Full  use.  I  completely  understand  how  to  use  it  and  without  it  my  job  would  be 
nuch  more  difficult.  I  could  teach  anyone  how  to  use  it  and  know  a*  of  its  features 


Figure  35:  System  functions,  objectives,  and  value  measures  for  reporting  template  and  comfort  during  dis¬ 
mounted  movement  functions. 
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Figure  36:  System  functions,  objectives,  and  value  measures  for  training  ease,  enemy  activity,  and  encryption 
functions. 
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ANNEX  C  -  Value  Models 
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